home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-tn3270e-enhancements-01.txt < prev    next >
Text File  |  1993-08-17  |  71KB  |  1,714 lines
  1.  
  2. TN3270 Enhancements Working Group                             B. Kelly
  3. Internet Draft                                       Auburn University
  4.                                                            August 1993
  5.  
  6.  
  7.                         TN3270 Enhancements
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This document is an Internet Draft.  Internet Drafts are working
  13.    documents of the Internet Engineering Task Force (IETF), its Areas,
  14.    and its Working Groups.  Note that other groups may also distribute
  15.    working documents as Internet Drafts.
  16.  
  17.    Internet Drafts are draft documents valid for a maximum of six
  18.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  19.    other documents at any time.  It is not appropriate to use Internet
  20.    Drafts as reference material or to cite them other than as a
  21.    "working draft" or "work in progress."
  22.  
  23.    Please check the 1id-abstracts.txt listing contained in the
  24.    internet-drafts Shadow Directories on ds.internic.net,
  25.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  26.    current status of any Internet Draft.
  27.  
  28. Abstract
  29.  
  30.    This document describes a protocol that more fully supports 3270
  31.    devices than do the existing tn3270 practices.  Specifically, it
  32.    defines a method of emulating both the terminal and printer members
  33.    of the 3270 family of devices via Telnet; it provides for the
  34.    ability of a Telnet client to request that it be assigned a
  35.    specific device-name (also referred to as "LU name" or "network
  36.    name"); finally, it adds support for a variety of functions such as
  37.    the ATTN key, the SYSREQ key, and SNA response handling.
  38.  
  39.    This protocol would be negotiated and implemented under a new
  40.    Telnet Option and would be unrelated to the Telnet 3270 Regime
  41.    Option as defined in RFC 1041 [1].
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. B. Kelly                 Expires February 1994                [Page 1]
  59.  
  60.  
  61. Internet Draft           TN3270 Enhancements               August 1993
  62.  
  63.  
  64. TABLE OF CONTENTS
  65.  
  66.    1.  INTRODUCTION ...............................................  2
  67.    2.  TN3270E OVERVIEW ...........................................  4
  68.    3.  COMMAND NAMES AND CODES ....................................  4
  69.    4.  COMMAND MEANINGS ...........................................  5
  70.    5.  DEFAULT SPECIFICATION ......................................  6
  71.    6.  MOTIVATION .................................................  7
  72.    7.  IMPLEMENTATION RULES .......................................  7
  73.       7.1  DEVICE-TYPE Negotiation ................................  7
  74.           7.1.1 Device Pools ......................................  7
  75.           7.1.2 CONNECT Command ...................................  8
  76.           7.1.3 ASSOCIATE Command .................................  9
  77.           7.1.4 Device Selection Rules ............................  9
  78.           7.1.5 Accepting a Request ............................... 10
  79.           7.1.6 REJECT Command .................................... 10
  80.       7.2  FUNCTIONS Negotiation .................................. 12
  81.           7.2.1 Commands .......................................... 12
  82.           7.2.2 List of TN3270E Functions ......................... 13
  83.    8.  TN3270E DATA MESSAGES ...................................... 13
  84.       8.1  The TN3270E Message Header ............................. 14
  85.           8.1.1 DATA-TYPE Field ................................... 14
  86.           8.1.2 REQUEST-FLAG Field ................................ 15
  87.           8.1.3 RESPONSE-FLAG Field ............................... 15
  88.    9.  BASIC TN3270E .............................................. 16
  89.       9.1  3270 Mode and NVT Mode ................................. 17
  90.    10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 18
  91.       10.1 The SCS-CTL-CODES Function ............................. 18
  92.       10.2 The DATA-STEAM-CTL Function ............................ 18
  93.       10.3 The BIND-IMAGE Function ................................ 19
  94.       10.4 The RESPONSE Function .................................. 20
  95.    11. THE 3270 ATTN KEY .......................................... 23
  96.    12. THE 3270 SYSREQ KEY ........................................ 23
  97.       12.1 Background ............................................. 23
  98.       12.2 TN3270E Implementation of SYSREQ ....................... 24
  99.    13. 3270 STRUCTURED FIELDS ..................................... 26
  100.    14. EXAMPLES ................................................... 26
  101.    15. REFERENCES ................................................. 28
  102.    16. AUTHOR'S NOTE .............................................. 29
  103.    17. AUTHOR'S ADDRESS ........................................... 29
  104.  
  105.  
  106. 1.  Introduction
  107.  
  108.    Currently, support for 3270 terminal emulation over Telnet is
  109.    accomplished by the de facto standard of negotiating three separate
  110.    Telnet Options - Terminal-Type [2], Binary Transmission [3], and
  111.    End of Record [4].  Note that there is no RFC that specifies this
  112.    negotiation as a standard.  RFC 1041 attempted to standardize the
  113.    method of negotiating 3270 terminal support by defining the 3270
  114.    Regime Telnet Option.  Unfortunately, very few developers and
  115.    vendors ever implemented RFC 1041.
  116.  
  117. B. Kelly                 Expires February 1994                [Page 2]
  118.  
  119.  
  120. Internet Draft           TN3270 Enhancements               August 1993
  121.  
  122.  
  123.    This document will refer to the existing practice of negotiating
  124.    these three Telnet Options before exchanging the 3270 data stream
  125.    as "traditional tn3270".
  126.  
  127.    NOTE: Except where otherwise stated, this document does not
  128.    distinguish between Telnet servers that represent SNA devices and
  129.    those that represent non-SNA 3270 devices.
  130.  
  131.    All references in this document to the 3270 data stream, 3270 data
  132.    stream commands, orders, structured fields and the like rely on
  133.    [5].  References to SNA Request and Response Units rely on [6].
  134.    References to SNA versus non-SNA operation rely on [7].
  135.  
  136.    There are several shortcomings in traditional tn3270; among them
  137.    are the following:
  138.  
  139.     - It provides no capability for Telnet clients to emulate the 328x
  140.       class of printers.
  141.  
  142.     - There is no mechanism by which a Telnet client can request that
  143.       a connection be associated with a given 3270 device-name.  This
  144.       can be of importance when a terminal session is being
  145.       established, since many host applications behave differently
  146.       depending on the network name of the terminal.  In the case of
  147.       printer emulation, this capability is an absolute necessity
  148.       because a large number of host applications have some method of
  149.       pre-defining printer destinations.
  150.  
  151.     - The 3270 ATTN and SYSREQ keys are not universally supported.
  152.  
  153.     - There is no support for the SNA positive/negative response
  154.       process.  This is particularly important if printer emulation is
  155.       to function properly, but is also useful for some terminal
  156.       applications.  A positive response is used to indicate that
  157.       the previously received data has been successfully processed.
  158.       A negative response indicates some sort of error has occurred
  159.       while processing the previously received data; this could be
  160.       caused by the host application building a 3270 data stream that
  161.       contains an invalid command, or by a mechanical error at the
  162.       client side, among other things.
  163.  
  164.     - There is no mechanism by which the client can access the SNA
  165.       Bind information.  The Bind image contains a detailed
  166.       description of the session between the Telnet server and the
  167.       host application.
  168.  
  169.     - There is no mechanism by which the server can determine whether
  170.       a client supports 3270 structured fields, or a client can
  171.       request that it receive them.
  172.  
  173.  
  174.  
  175.  
  176. B. Kelly                 Expires February 1994                [Page 3]
  177.  
  178.  
  179. Internet Draft           TN3270 Enhancements               August 1993
  180.  
  181.  
  182. 2.  TN3270E Overview
  183.  
  184.    In order to address these issues, this document proposes a new
  185.    Telnet Option - TN3270E (option number has yet to be assigned).
  186.    Telnet clients and servers would be free to negotiate support of
  187.    the TN3270E option or not. If either side does not support TN3270E,
  188.    traditional tn3270 can be used; otherwise, a sub-negotiation will
  189.    occur to determine what subset of TN3270E will be used on the
  190.    session.  It is anticipated that a client or server capable of both
  191.    types of 3270 emulation would attempt to negotiate TN3270E first,
  192.    and only negotiate traditional tn3270 if the other side refuses
  193.    TN3270E.
  194.  
  195.    Once a client and server have agreed to use TN3270E, negotiation of
  196.    the TN3270E suboptions can begin.  The two major elements of
  197.    TN3270E sub-negotiation are:
  198.  
  199.     - a device-type negotiation that is similar to, but somewhat
  200.       more complicated than, the existing Telnet Terminal-Type Option.
  201.  
  202.     - the negotiation of a set of supported 3270 functions, such as
  203.       printer data stream type (3270 data stream or SNA Character
  204.       Stream), positive/negative response exchanges, device status
  205.       information, and the passing of BIND information from server to
  206.       client.
  207.  
  208.    Successful negotiation of these two suboptions signals the
  209.    beginning of 3270 data stream transmission. In order to support
  210.    several of the new functions in TN3270E, each data message must be
  211.    prefixed by a header.  This header will contain flags and
  212.    indicators that convey such things as positive and negative
  213.    responses and what type of data follows the header (for example,
  214.    3270 data stream, SNA Character Stream, or device status
  215.    information).
  216.  
  217.  
  218. 3.  Command Names and Codes
  219.  
  220.        TN3270E        (to be assigned)
  221.          ASSOCIATE          00
  222.          CONNECT            01
  223.          DEVICE-TYPE        02
  224.          FUNCTIONS          03
  225.          IS                 04
  226.          REASON             05
  227.          REJECT             06
  228.          REQUEST            07
  229.          SEND               08
  230.  
  231.  
  232.  
  233.  
  234.  
  235. B. Kelly                 Expires February 1994                [Page 4]
  236.  
  237.  
  238. Internet Draft           TN3270 Enhancements               August 1993
  239.  
  240.  
  241.        Reason-codes
  242.          CONN-PARTNER       00
  243.          DEVICE-IN-USE      01
  244.          INV-ASSOCIATE      02
  245.          INV-DEVICE-NAME    03
  246.          INV-DEVICE-TYPE    04
  247.          TYPE-NAME-ERROR    05
  248.          UNKNOWN-ERROR      06
  249.          UNSUPPORTED-REQ    07
  250.  
  251.        Function Names
  252.          BIND-IMAGE         00
  253.          DATA-STREAM-CTL    01
  254.          RESPONSES          02
  255.          SCS-CTL-CODES      03
  256.  
  257.  
  258. 4.  Command Meanings
  259.  
  260.    IAC WILL TN3270E
  261.  
  262.       The sender of this command is willing to send TN3270E
  263.       information in subsequent sub-negotiations.
  264.  
  265.    IAC WON'T TN3270E
  266.  
  267.       The sender of this command refuses to send TN3270E information.
  268.  
  269.    IAC DO TN3270E
  270.  
  271.       The sender of this command is willing to receive TN3270E
  272.       information in subsequent sub-negotiations.
  273.  
  274.    IAC DON'T TN3270E
  275.  
  276.       The sender of this command refuses to receive TN3270E
  277.       information.
  278.  
  279.    Note that while they are not explicitly negotiated, the equivalent
  280.    of the Telnet Binary Transmission Option [3] and the Telnet End of
  281.    Record Option [4] is implied in the negotiation of the TN3270E
  282.    Option.  That is, a party to the negotiation that agrees to support
  283.    TN3270E is automatically required to support bi-directional binary
  284.    and EOR transmissions.
  285.  
  286.    IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  287.  
  288.       Only the server may send this command.  This command is used to
  289.       request that the client transmit a device-type and, optionally,
  290.       device-name information.
  291.  
  292.  
  293.  
  294. B. Kelly                 Expires February 1994                [Page 5]
  295.  
  296.  
  297. Internet Draft           TN3270 Enhancements               August 1993
  298.  
  299.  
  300.    IAC SB TN3270E DEVICE-TYPE REQUEST <device-type>
  301.           [CONNECT | ASSOCIATE <device-name>] IAC SE
  302.  
  303.       Only the client may send this command.  It is used in response
  304.       to the server's SEND DEVICE-TYPE command, as well as to suggest
  305.       another device-type after the server has sent a DEVICE-TYPE
  306.       REJECT command (see below).  This command requests emulation of
  307.       a specific 3270 device type and model.  The REQUEST command may
  308.       optionally include either the CONNECT or the ASSOCIATE command
  309.       (but not both).  If present, CONNECT and ASSOCIATE must both be
  310.       followed by <device-name>.  (See the section entitled
  311.       "Implementation Rules" for more detailed information.)
  312.  
  313.    IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT
  314.           <device-name> IAC SE
  315.  
  316.       Only the server may send this command.  This command is used to
  317.       accept a client's DEVICE-TYPE REQUEST command.
  318.  
  319.    IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE
  320.  
  321.       Only the server may send this command.  This command is used to
  322.       reject a client's DEVICE-TYPE REQUEST command.
  323.  
  324.    IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC SE
  325.  
  326.       Either side may send this command.  This command is used to
  327.       suggest a set of 3270 functions that will be supported on this
  328.       session.  It is also sent as an implicit rejection of a previous
  329.       FUNCTIONS REQUEST command sent by the other side (see the
  330.       section entitled "Implementation Rules" for more information).
  331.       Note that when used to reject a FUNCTIONS REQUEST command, the
  332.       function-list must not be identical to that received in the
  333.       previous REQUEST command.
  334.  
  335.    IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE
  336.  
  337.       Either side may send this command.  This command is sent as a
  338.       response to a FUNCTIONS REQUEST command and implies acceptance
  339.       of the set of functions sent to it in the REQUEST command.  Note
  340.       that the list of functions in the FUNCTIONS IS command must
  341.       match the list that was received in the previous FUNCTIONS
  342.       REQUEST command.
  343.  
  344.  
  345. 5.  Default Specification
  346.  
  347.    WON'T TN3270E
  348.  
  349.    DON'T TN3270E
  350.  
  351.    i.e., TN3270E will not be used.
  352.  
  353. B. Kelly                 Expires February 1994                [Page 6]
  354.  
  355.  
  356. Internet Draft           TN3270 Enhancements               August 1993
  357.  
  358.  
  359. 6.  Motivation
  360.  
  361.    See the section entitled "Introduction."
  362.  
  363.  
  364. 7.  Implementation Rules
  365.  
  366.    All TN3270E commands and parameters are NVT ASCII strings in which
  367.    upper and lower case are considered equivalent.
  368.  
  369.    Once it has been agreed that TN3270E will be supported, the first
  370.    sub-negotiation must concern the DEVICE-TYPE (and possibly
  371.    DEVICE-NAME) information.  Only after that has been successfully
  372.    negotiated can the client and server exchange FUNCTIONS
  373.    information.  Only after both DEVICE-TYPE and FUNCTIONS have been
  374.    successfully negotiated can 3270 data stream transmission occur.
  375.  
  376.  
  377.    7.1 DEVICE-TYPE Negotiation
  378.  
  379.       Device-type (and device-name) negotiation begins when the server
  380.       transmits the DEVICE-TYPE SEND command to the client.  The
  381.       client responds with the DEVICE-TYPE REQUEST command, which must
  382.       include a device-type and may include a device-name request.
  383.  
  384.       Valid device-types are:
  385.  
  386.         terminals: IBM-3278-2-E
  387.                    IBM-3278-3-E
  388.                    IBM-3278-4-E
  389.                    IBM-3278-5-E
  390.                    IBM-3279-2-E
  391.                    IBM-3279-3-E
  392.  
  393.          printers: IBM-3287-1
  394.  
  395.  
  396.      7.1.1 Device Pools
  397.  
  398.       An explanation of the CONNECT and ASSOCIATE commands first
  399.       requires a discussion of the organization of terminal and
  400.       printer device pools that the server maintains and from which it
  401.       selects device-names to assign to session requests.  (The terms
  402.       "device-name", "LU name" and "network name" can be considered
  403.       interchangeable in this document.)  Also, for the purposes of
  404.       this discussion, the term "generic session request" will be used
  405.       to describe a request for a session from a Telnet client (either
  406.       traditional or TN3270E) that does not include a request for a
  407.       specific device-name.  The term "specific session request" will
  408.       be used to describe a request for a session from a TN3270E
  409.       client that includes a request for a specific device-name
  410.       (either via CONNECT or ASSOCIATE).
  411.  
  412. B. Kelly                 Expires February 1994                [Page 7]
  413.  
  414.  
  415. Internet Draft           TN3270 Enhancements               August 1993
  416.  
  417.  
  418.       As is the case with traditional tn3270, the TN3270E server must
  419.       maintain a set of terminal device-names.  A generic request for
  420.       a terminal session would result in the server selecting any
  421.       available device-name from this pool.  The server, however, may
  422.       also maintain a separate pool of terminal device-names which can
  423.       only be used to satisfy specific terminal session requests.
  424.       This is to ensure that a terminal device that has some
  425.       significance to host applications (and is therefore likely to be
  426.       the target of a specific session request) is not "accidentally"
  427.       assigned to a generic request and winds up associated with a
  428.       client that has no use for it.  Note that the reverse situation
  429.       is allowed.  That is, a specific terminal session request could
  430.       ask for a device-name that happens to be in the "generic
  431.       terminal pool."
  432.  
  433.       For each terminal device (in both the "generic" and the
  434.       "specific" pools), the TN3270E server could also have defined a
  435.       "partner" or "paired" printer device.  There should be a unique,
  436.       one-to-one mapping between a terminal and its associated
  437.       printer.  The reasoning behind such a configuration is to allow
  438.       for those host applications that produce printed output bound
  439.       for a printer whose device-name is determined by the device-name
  440.       of the terminal that initiated the print request.  These printer
  441.       devices can only be assigned to specific printer session
  442.       requests that use the ASSOCIATE command (see below).
  443.  
  444.       In addition, the TN3270E server may also maintain a pool of
  445.       printer device-names that are not associated with any terminal.
  446.       These printer devices can only be assigned to specific printer
  447.       session requests that use the CONNECT command (see below).  This
  448.       allows for those host applications that generate printed output
  449.       bound for a printer whose device-name is determined by something
  450.       other than the device-name of the terminal that initiated the
  451.       print request (for example, when the userid of the person signed
  452.       on to a terminal determines the print destination).
  453.  
  454.       Finally, it is possible that a pool of printer device-names
  455.       could be maintained and used only to satisfy generic requests
  456.       for printers.
  457.  
  458.  
  459.      7.1.2 CONNECT Command
  460.  
  461.       CONNECT is used by the client to request that the server assign
  462.       a specific device-name to this Telnet session; it may be used
  463.       when requesting either a terminal or a printer session.  The
  464.       specified device-name must not conflict with the device-type;
  465.       e.g., if the client requests DEVICE-TYPE IBM-3287-1 (a printer)
  466.       and specifies CONNECT T1000001, but T1000001 is defined at the
  467.       host as a terminal, then the server should deny the request.
  468.  
  469.  
  470.  
  471. B. Kelly                 Expires February 1994                [Page 8]
  472.  
  473.  
  474. Internet Draft           TN3270 Enhancements               August 1993
  475.  
  476.  
  477.       Further, if the requested device-name is already associated with
  478.       some other Telnet session, or if it is not defined to the
  479.       server, the server should deny the request.
  480.  
  481.  
  482.      7.1.3 ASSOCIATE Command
  483.  
  484.       ASSOCIATE can be used by the client only when requesting a
  485.       DEVICE-TYPE that represents a printer. The ASSOCIATE command
  486.       requests that this session be assigned the device-name of the
  487.       printer that is paired with the terminal named in the request.
  488.       If the device-type does not represent a printer, or if the
  489.       device-name is not that of a terminal, then the server should
  490.       deny the request.  It is anticipated that the device-name
  491.       specified in this request would be one returned by the server
  492.       when accepting a previous terminal session request (see the IS
  493.       command below).  Since no means of authentication has been
  494.       provided for, it is possible that the printer paired with the
  495.       terminal specified in the ASSOCIATE command has already been
  496.       assigned to some other Telnet session; in this case, the server
  497.       should deny the request.
  498.  
  499.  
  500.      7.1.4 Device Selection Rules
  501.  
  502.       To summarize, assume a TN3270E server has the following device
  503.       pools defined to it (device-names that begin with a "T" are
  504.       terminal devices; those that begin with a "P" are printers):
  505.  
  506.        Generic Terminal Pool              Specific Terminal Pool
  507.        ---------------------              ----------------------
  508.        TG000001 <--> PTG00001             TS000001 <--> PTS00001
  509.        TG000002 <--> PTG00002             TS000002 <--> PTS00002
  510.        TG000003 <--> PTG00003             TS000003 <--> PTS00003
  511.  
  512.        Generic Printer Pool               Specific Printer Pool
  513.        --------------------               ----------------------
  514.             PG000001                            PS000001
  515.             PG000002                            PS000002
  516.             PG000003                            PS000003
  517.  
  518.       Note that the only pool that absolutely must be defined to the
  519.       server is the generic terminal pool.  The absence of other pools
  520.       (or of partner printers for a terminal pool) simply means that
  521.       the server is unable to satisfy as wide a variety of requests as
  522.       would be possible if all pools were defined to it.
  523.  
  524.       Given the above configuration, the following rules apply:
  525.  
  526.       - a generic terminal request can only be satisfied from the
  527.         generic terminal pool (device-names TG000001 - TG000003).
  528.  
  529.  
  530. B. Kelly                 Expires February 1994                [Page 9]
  531.  
  532.  
  533. Internet Draft           TN3270 Enhancements               August 1993
  534.  
  535.  
  536.       - a specific terminal request (allowable only via the CONNECT
  537.         command) can be satisfied from either the generic or the
  538.         specific terminal pool, although it is anticipated that the
  539.         majority of such requests would ask for terminals in the
  540.         specific terminal pool (TS000001 - TS000003).
  541.  
  542.       - a generic printer request can only be satisfied from the
  543.         generic printer pool (device-names PG000001 - PG000003).
  544.  
  545.       - a specific printer request may come in one of two forms:
  546.  
  547.         via ASSOCIATE: the request can only be satisfied using the
  548.                        partner of the specified terminal, which
  549.                        may be in the generic or the specific
  550.                        terminal pool; therefore, devices in the
  551.                        ranges PTG00001 - PTG00003 and PTS00001 -
  552.                        PTS00003 can be used to satisfy the request.
  553.  
  554.         via CONNECT:   the request can be satisfied either from
  555.                        the generic or the specific printer pools
  556.                        (although, as with specific terminal requests,
  557.                        it is likely that most such requests will name
  558.                        printers in the specific printer pool); this
  559.                        request cannot be satisfied with the partner
  560.                        printer of a terminal in either the specific or
  561.                        the generic terminal pools.
  562.  
  563.  
  564.      7.1.5 Accepting a Request
  565.  
  566.       The server must accept the client's request or deny it as a
  567.       whole - it cannot, for example, accept the DEVICE-TYPE request
  568.       but deny the CONNECT portion.
  569.  
  570.       If the server wishes to accept the request, it sends back the
  571.       DEVICE-TYPE IS command confirming the requested device-type and
  572.       the CONNECT command specifying the device-name of the terminal
  573.       or printer assigned to this Telnet session.  This device-name
  574.       may be the one directly requested (via CONNECT) by the client,
  575.       the one indirectly requested (via ASSOCIATE) by the client, or
  576.       one chosen by the server if the client specified neither CONNECT
  577.       nor ASSOCIATE.
  578.  
  579.  
  580.      7.1.6 REJECT Command
  581.  
  582.       If the server wishes to deny the request, it sends back the
  583.       DEVICE-TYPE REJECT command with one of the following
  584.       reason-codes:
  585.  
  586.  
  587.  
  588.  
  589. B. Kelly                 Expires February 1994               [Page 10]
  590.  
  591.  
  592. Internet Draft           TN3270 Enhancements               August 1993
  593.  
  594.  
  595.          Reason code name         Explanation
  596.          ----------------         -----------------------------------
  597.          INV-DEVICE-TYPE          The server does not support the
  598.                                   requested device-type.
  599.  
  600.          INV-DEVICE-NAME          The device-name specified in the
  601.                                   CONNECT or ASSOCIATE command is
  602.                                   not known to the server.
  603.  
  604.          DEVICE-IN-USE            The requested device-name is
  605.                                   already associated with another
  606.                                   Telnet session.
  607.  
  608.          TYPE-NAME-ERROR          The requested device-name is
  609.                                   incompatible with the requested
  610.                                   device-type (such as terminal/
  611.                                   printer mismatch).
  612.  
  613.          UNSUPPORTED-REQ          The server is unable to satisfy
  614.                                   the type of request sent by the
  615.                                   client; e.g., a specific terminal
  616.                                   or printer was requested but the
  617.                                   server does not have such a pool of
  618.                                   device-names defined to it, or the
  619.                                   ASSOCIATE command was used but no
  620.                                   partner printers are defined to the
  621.                                   server.
  622.  
  623.          INV-ASSOCIATE            The client used the ASSOCIATE
  624.                                   command and either the device-type
  625.                                   is not a printer or the device-name
  626.                                   is not a terminal.
  627.  
  628.          CONN-PARTNER             The client used the CONNECT command
  629.                                   to request a specific printer but
  630.                                   the device-name requested is the
  631.                                   partner to some terminal.
  632.  
  633.          UNKNOWN-ERROR            Any other error in device type or
  634.                                   name processing has occurred.
  635.  
  636.       The process of negotiating a device-type and device-name that
  637.       are acceptable to both client and server may entail several
  638.       iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT
  639.       commands.  The client should make use of the reason-code
  640.       specified by the server in any DEVICE-TYPE REJECT command(s) to
  641.       minimize the amount of negotiation necessary.  For example, if
  642.       the client initially requests that it be assigned a specific
  643.       terminal device-name via the CONNECT command, and the server
  644.       rejects the request with a reason-code of UNSUPPORTED-REQ, the
  645.       client should make no further specific terminal requests in the
  646.  
  647.  
  648. B. Kelly                 Expires February 1994               [Page 11]
  649.  
  650.  
  651. Internet Draft           TN3270 Enhancements               August 1993
  652.  
  653.  
  654.       negotiations.  If at any point in the process either side wishes
  655.       to "bail out," it can simply send a WON'T (or DON'T) TN3270E
  656.       command to the other side.  At this point both sides are free to
  657.       negotiate other Telnet options (including traditional tn3270).
  658.  
  659.  
  660.    7.2 FUNCTIONS Negotiation
  661.  
  662.       Once the DEVICE-TYPE negotiation has successfully completed
  663.       (i.e, when the client receives the DEVICE-TYPE IS command), the
  664.       client should initiate the FUNCTIONS negotiation by sending the
  665.       FUNCTIONS REQUEST command to the server.  After this initial
  666.       REQUEST command, both sides are free to transmit FUNCTIONS
  667.       REQUEST and FUNCTIONS IS commands as needed.
  668.  
  669.  
  670.      7.2.1 Commands
  671.  
  672.       The FUNCTIONS REQUEST command contains a list of the 3270
  673.       functions that the sender would like to see supported on this
  674.       session.  All functions not in the list are to be considered
  675.       unsupported.  The function-list consists of a string of 2-byte
  676.       entries separated from one another by a single space character.
  677.       The list is terminated by the IAC code that precedes the SE
  678.       command.  Functions may appear in any order in the list.
  679.  
  680.       Upon receipt of a FUNCTIONS REQUEST command, the recipient has
  681.       two choices:
  682.  
  683.        - it may respond in the positive (meaning it agrees to support
  684.          all functions in the list, and not to transmit any data
  685.          related to functions not in the list).  To do this, it sends
  686.          the FUNCTIONS IS command with the function-list exactly as it
  687.          was received.  At this point, FUNCTIONS negotiation has
  688.          successfully completed.
  689.  
  690.        - it may respond in the negative by sending a FUNCTIONS
  691.          REQUEST command in which the function-list differs from the
  692.          one it received (and not simply in the order of appearance
  693.          of functions in the list; at least one function must have
  694.          been added to, or removed from, the list).
  695.  
  696.       To avoid endlessly looping, neither party should add to the
  697.       function-list it receives any function that it has previously
  698.       added and that the other side has removed.
  699.  
  700.       The process of sending FUNCTIONS REQUEST commands back and forth
  701.       continues until one side receives a function-list it is willing
  702.       to live with.  It uses the FUNCTIONS IS command to accept the
  703.       list, and, once this command is received by the other side, all
  704.       necessary negotiation has been completed.  At this point, 3270
  705.       data stream transmission can begin.
  706.  
  707. B. Kelly                 Expires February 1994               [Page 12]
  708.  
  709.  
  710. Internet Draft           TN3270 Enhancements               August 1993
  711.  
  712.  
  713.       Note that it is possible that the function-list agreed to is
  714.       null; this is referred to as "basic TN3270E."  See the section
  715.       entitled "Basic TN3270E" for more information.
  716.  
  717.  
  718.      7.2.2 List of TN3270E Functions
  719.  
  720.       The following list briefly describes the 3270 functions that may
  721.       be negotiated in the function-list:
  722.  
  723.           Function Name       Description
  724.           -------------       -----------
  725.          SCS-CTL-CODES       (Printer sessions only).  Allows the use
  726.                              of the SNA Character Stream (SCS) and SCS
  727.                              control codes on the session.  SCS is
  728.                              used with LU type 1 SNA sessions.
  729.  
  730.          DATA-STREAM-CTL     (Printer sessions only).  Allows the use
  731.                              of the standard 3270 data stream. This
  732.                              corresponds to LU type 3 SNA sessions.
  733.                              DATA-STREAM-CTL is mutually exclusive
  734.                              with SCS-CTL-CODES (only one of these
  735.                              should appear in a function-list).
  736.  
  737.          RESPONSES           Provides support for positive and
  738.                              negative response handling.  Allows the
  739.                              server to reflect to the client any and
  740.                              all definite, exception, and no response
  741.                              requests sent by the host application.
  742.  
  743.          BIND-IMAGE          Allows the server to send the SNA Bind
  744.                              image and Unbind notification to the
  745.                              client.
  746.  
  747.       See the section entitled "Details of Processing TN3270E
  748.       Functions" for a more detailed explanation of the meaning and
  749.       use of these functions.
  750.  
  751.  
  752. 8.  TN3270E Data Messages
  753.  
  754.    3270 device communications are generally understood to be block
  755.    oriented in nature.  That is, each partner buffers data until an
  756.    entire "message" has been built, at which point the data is sent to
  757.    the other side.  The "message" consists of a series of 3270
  758.    commands, buffer orders, buffer addresses, and data.  The end of a
  759.    message is understood to be the last byte transmitted (note that
  760.    this discussion disregards SNA chaining).  The Telnet EOR command
  761.    is used to delimit these natural 3270 blocks of data within the
  762.    Telnet data stream.
  763.  
  764.  
  765.  
  766. B. Kelly                 Expires February 1994               [Page 13]
  767.  
  768.  
  769. Internet Draft           TN3270 Enhancements               August 1993
  770.  
  771.  
  772.    In TN3270E, each 3270 message must be prefixed with a TN3270E
  773.    header, which consists of four bytes and whose format is defined
  774.    below (see the section entitled "The TN3270E Message Header").
  775.  
  776.    A "data message" in TN3270E therefore has the following
  777.    construction:
  778.  
  779.           <TN3270E Header><data><IAC EOR>
  780.  
  781.    It should be noted that it is possible that, for certain message
  782.    types, there is no data portion present.  In this case, the TN3270E
  783.    data message consists of:
  784.  
  785.           <TN3270E Header><IAC EOR>
  786.  
  787.    Note also that Telnet commands may appear anywhere in the Telnet
  788.    stream.  For this reason, if either side wishes to transmit the
  789.    decimal value 255 and have it interpreted as data, it must "double"
  790.    this byte.  In other words, a single occurrence of decimal 255 will
  791.    be interpreted by the other side as an IAC, while two successive
  792.    bytes containing decimal 255 will be treated as one data byte with
  793.    a value of decimal 255.
  794.  
  795.  
  796.    8.1 The TN3270E Message Header
  797.  
  798.       As stated earlier, each data message in TN3270E must be prefixed
  799.       by a header, which consists of four bytes and is formatted as
  800.       follows:
  801.  
  802.           ------------------------------------------------
  803.           |   DATA-TYPE   | REQUEST-FLAG | RESPONSE-FLAG |
  804.           ------------------------------------------------
  805.                2 bytes         1 byte         1 byte
  806.  
  807.  
  808.      8.1.1 DATA-TYPE Field
  809.  
  810.       The DATA-TYPE field indicates how the data portion of the
  811.       message is to be interpreted by the receiver.  Possible values
  812.       for the DATA-TYPE field are:
  813.  
  814.         Data-type Name   Code                Meaning
  815.         --------------   ----   ---------------------------------
  816.         3270-DATA         00    The data portion of the message
  817.                                 contains only the 3270 data stream.
  818.  
  819.         SCS-DATA          01    The data portion of the message
  820.                                 contains SNA Character Stream data.
  821.  
  822.  
  823.  
  824.  
  825. B. Kelly                 Expires February 1994               [Page 14]
  826.  
  827.  
  828. Internet Draft           TN3270 Enhancements               August 1993
  829.  
  830.  
  831.         RESPONSE          02    The data portion of the message
  832.                                 constitutes device-status information
  833.                                 and the RESPONSE-FLAG field indicates
  834.                                 whether this is a positive or negative
  835.                                 response (see below).
  836.  
  837.         BIND-IMAGE        03    The data portion of the message is
  838.                                 the SNA bind image from the session
  839.                                 established between the server and the
  840.                                 host application.
  841.  
  842.         UNBIND            04    The data portion of the message is
  843.                                 an Unbind reason code.
  844.  
  845.         NVT-DATA          05    The data portion of the message is to
  846.                                 be interpreted as NVT data.
  847.  
  848.         REQUEST           06    There is no data portion present in
  849.                                 the message.  Only the REQUEST-FLAG
  850.                                 field has any meaning.
  851.  
  852.  
  853.      8.1.2 REQUEST-FLAG Field
  854.  
  855.       The REQUEST-FLAG field only has meaning when the DATA-TYPE field
  856.       has a value of REQUEST; otherwise, the REQUEST-FLAG field must
  857.       be ignored by the receiver and should be set to 0x00 by the
  858.       sender.  Possible values for the REQUEST-FLAG field are:
  859.  
  860.         Request-Flag Name   Code                Meaning
  861.         -----------------   ----   ---------------------------------
  862.         ERR-COND-CLEARED      0    The client sends this to the server
  863.                                    when some previously encountered
  864.                                    printer error condition has been
  865.                                    cleared.  (See the section entitled
  866.                                    "The RESPONSE Function" below.)
  867.  
  868.  
  869.      8.1.3 RESPONSE-FLAG Field
  870.  
  871.       The RESPONSE-FLAG field only has meaning for certain values of
  872.       the DATA-TYPE field.  For DATA-TYPE field values of 3270-DATA
  873.       and SCS-DATA, the RESPONSE-FLAG is an indication of whether or
  874.       not the sender of the data expects to receive a response.  In
  875.       this case the possible values of RESPONSE-FLAG are:
  876.  
  877.         Response-Flag Name  Code                Meaning
  878.         ------------------  ----   ---------------------------------
  879.         NO-RESPONSE           0    The sender does not expect the
  880.                                    receiver to respond either
  881.  
  882.  
  883.  
  884. B. Kelly                 Expires February 1994               [Page 15]
  885.  
  886.  
  887. Internet Draft           TN3270 Enhancements               August 1993
  888.  
  889.  
  890.                                    positively or negatively to this
  891.                                    message.
  892.  
  893.         ERROR-RESPONSE        1    The sender only expects the
  894.                                    receiver to respond to this message
  895.                                    if some type of error occurred, in
  896.                                    which case a negative response is
  897.                                    expected.
  898.  
  899.         ALWAYS-RESPONSE       2    The sender expects the receiver to
  900.                                    respond negatively if an error
  901.                                    occurs, or positively if no errors
  902.                                    occur.
  903.  
  904.       For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is an
  905.       actual response to the previous data message (which must by
  906.       definition have had a DATA-TYPE of either 3270-DATA or SCS-DATA
  907.       and a RESPONSE-FLAG value of either ERROR-RESPONSE or
  908.       ALWAYS-RESPONSE).  In this case the possible values of
  909.       RESPONSE-FLAG are:
  910.  
  911.         Response-Flag Name  Code                Meaning
  912.         ------------------  ----   ---------------------------------
  913.         POSITIVE-RESPONSE     0    The previous message was received
  914.                                    and executed successfully with
  915.                                    no errors.
  916.  
  917.         NEGATIVE-RESPONSE     1    The previous message was received
  918.                                    but an error(s) occurred while
  919.                                    processing it.
  920.  
  921.       Accompanying device status information will be found in the data
  922.       portion of the message.
  923.  
  924.       For any other values of the DATA-TYPE field, the RESPONSE-FLAG
  925.       field must be ignored by the receiver and should be set to 0x00
  926.       by the sender.
  927.  
  928.  
  929. 9.  Basic TN3270E
  930.  
  931.    As has been stated earlier, whether or not the use of each of the
  932.    TN3270E functions is allowed on a session is negotiated when the
  933.    connection is established.  It is possible that none of the
  934.    functions are agreed to (in this case, the function-list in the
  935.    FUNCTIONS REQUEST and FUNCTIONS IS commands is null).  This
  936.    mode of operation is referred to as "basic TN3270E."  Note that,
  937.    since neither SCS-CTL-CODES nor DATA-STREAM-CTL is negotiated,
  938.    basic TN3270E refers to terminal sessions only.
  939.  
  940.  
  941.  
  942.  
  943. B. Kelly                 Expires February 1994               [Page 16]
  944.  
  945.  
  946. Internet Draft           TN3270 Enhancements               August 1993
  947.  
  948.  
  949.    Basic TN3270E requires the support of only the following TN3270E
  950.    header values:
  951.  
  952.           Header field         Value
  953.           ------------         -----
  954.            DATA-TYPE          3270-DATA
  955.            DATA-TYPE          SCS-DATA
  956.            DATA-TYPE          NVT-DATA
  957.  
  958.    The REQUEST-FLAG and RESPONSE-FLAG fields are not used in basic
  959.    TN3270E.
  960.  
  961.  
  962.    9.1 3270 Mode and NVT Mode
  963.  
  964.       At any given time, a TN3270E connection can be considered to be
  965.       operating in either "3270 mode" or "NVT mode."  In 3270 mode,
  966.       each party may send data messages with the DATA-TYPE flag set to
  967.       either 3270-DATA or SCS-DATA (SCS-DATA is used only in support
  968.       of the SYSREQ key); sending a DATA-TYPE flag set to NVT-DATA
  969.       constitutes a request to switch modes.  In NVT mode, each party
  970.       may send data messages with the DATA-TYPE flag set to NVT-DATA;
  971.       sending 3270-DATA or SCS-DATA is a request to switch modes.  The
  972.       connection is initially in 3270 mode when TN3270E operation is
  973.       successfully negotiated.  When a party receives a message with a
  974.       DATA-TYPE different from the mode it is operating in, the mode
  975.       of operation for the connection is switched.  Switching modes
  976.       results in the client performing the equivalent of a 3270
  977.       Erase/Reset operation, as described in [5], using the default
  978.       partition size.  The server cannot assume the client preserves
  979.       any attributes of the previous environment across a mode
  980.       switch.
  981.  
  982.       Note that even when sending NVT-DATA, each side should buffer
  983.       data until an entire message is built (for the client, this
  984.       would normally mean until the user presses Enter).  At that
  985.       point, a complete TN3270E data message should be built to
  986.       transmit the NVT data.
  987.  
  988.       Typically, NVT data is used by a server to interact with the
  989.       user of a client.  It allows the server to do this using a
  990.       simple NVT data stream, instead of requiring a 3270 data stream.
  991.       An example would be a server which displays a list of 3270
  992.       applications to which it can connect the client.  The server
  993.       would use NVT data to display the list and read the user's
  994.       choice.  Then the server would connect to the application, and
  995.       begin the exchange of 3270 data between the application and the
  996.       client.
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002. B. Kelly                 Expires February 1994               [Page 17]
  1003.  
  1004.  
  1005. Internet Draft           TN3270 Enhancements               August 1993
  1006.  
  1007.  
  1008. 10. Details of Processing TN3270E Functions
  1009.  
  1010.    Agreement by both parties to a specific function in the FUNCTIONS
  1011.    REQUEST function-list implies agreement by each party to support a
  1012.    related set of values in the TN3270E header.  It also implies a
  1013.    willingness to adhere to the rules governing the processing of data
  1014.    messages as regards the agreed upon function.  Either party that
  1015.    fails to accept header values associated either with agreed upon
  1016.    functions or with basic TN3270E, or attempts to use header values
  1017.    associated with a function that is not a part of basic TN3270E and
  1018.    was not agreed upon, will be considered non-conforming and in
  1019.    violation of the protocol.  The following sections detail for each
  1020.    TN3270E function the associated header values and processing
  1021.    rules.
  1022.  
  1023.  
  1024.    10.1 The SCS-CTL-CODES Function
  1025.  
  1026.       This function can only be supported on a 3270 printer session.
  1027.       If either party receives this function in a FUNCTIONS REQUEST
  1028.       function-list when the previously negotiated device-type
  1029.       represents a terminal, it must remove the SCS-CTL-CODES function
  1030.       from the list before responding with a FUNCTIONS REQUEST of its
  1031.       own.  Either SCS-CTL-CODES or DATA-STREAM-CTL must be agreed to
  1032.       by both parties when the negotiated device-type represents a
  1033.       printer.
  1034.  
  1035.       Agreement to support this function requires that the party
  1036.       support the following TN3270E header values:
  1037.  
  1038.           Header field         Value
  1039.           ------------         -----
  1040.            DATA-TYPE          SCS-DATA
  1041.  
  1042.       When SCS-CTL-CODES is in effect, neither side should send a data
  1043.       message with a DATA-TYPE of 3270-DATA.
  1044.  
  1045.  
  1046.    10.2 The DATA-STREAM-CTL Function
  1047.  
  1048.       This function can only be supported on a 3270 printer session.
  1049.       If either party receives this function in a FUNCTIONS REQUEST
  1050.       function-list when the previously negotiated device-type
  1051.       represents a terminal, it must remove the DATA-STREAM-CTL
  1052.       function from the list before responding with a FUNCTIONS
  1053.       REQUEST of its own.
  1054.  
  1055.       Agreement to support this function requires that the party
  1056.       support the following TN3270E header values:
  1057.  
  1058.  
  1059.  
  1060.  
  1061. B. Kelly                 Expires February 1994               [Page 18]
  1062.  
  1063.  
  1064. Internet Draft           TN3270 Enhancements               August 1993
  1065.  
  1066.  
  1067.           Header field         Value
  1068.           ------------         -----
  1069.            DATA-TYPE          3270-DATA
  1070.  
  1071.       When DATA-STREAM-CTL is in effect, neither side should send a
  1072.       data message with a DATA-TYPE of SCS-DATA.
  1073.  
  1074.  
  1075.    10.3 The BIND-IMAGE Function
  1076.  
  1077.       This function can only be supported when the TN3270E server
  1078.       represents SNA terminals and printers.
  1079.  
  1080.       Agreement to support this function requires that the party
  1081.       support the following TN3270E header values:
  1082.  
  1083.           Header field         Value
  1084.           ------------         -----
  1085.            DATA-TYPE          BIND-IMAGE
  1086.            DATA-TYPE          UNBIND
  1087.  
  1088.       When BIND-IMAGE is in effect, the server must inform the client
  1089.       when an SNA session has been established with a host
  1090.       application, and when such a session has been terminated.  It
  1091.       uses DATA-TYPE values of BIND-IMAGE and UNBIND to convey this
  1092.       information.
  1093.  
  1094.       When establishing an SNA session on behalf of a client, the
  1095.       server will receive a Bind RU from the host application.  It
  1096.       will also receive a Start Data Traffic RU.  Once both of these
  1097.       have been responded to positively by the server, it must then
  1098.       inform the client of the presence of this session by sending it
  1099.       a data message with the DATA-TYPE flag set to BIND-IMAGE.  The
  1100.       data portion of this message must contain the bind image exactly
  1101.       as it was received in the Bind RU that the server accepted on
  1102.       behalf of the client.
  1103.  
  1104.       When an SNA session between the server and a host application is
  1105.       terminated, the server should send a data message to the client
  1106.       with the DATA-TYPE flag set to UNBIND.  If the server was
  1107.       notified of the session termination via an Unbind SNA RU, it
  1108.       should include the Unbind reason code in the data portion of the
  1109.       message it sends to the client.  If the server itself requested
  1110.       the SNA session termination (for example, as part of SYSREQ key
  1111.       processing), it should set the data portion of the UNBIND
  1112.       message to 0x01, indicating "normal end of session."
  1113.  
  1114.       A client that agrees to the BIND-IMAGE function must be ready to
  1115.       accept BIND-IMAGE and UNBIND data messages at any time.
  1116.  
  1117.  
  1118.  
  1119.  
  1120. B. Kelly                 Expires February 1994               [Page 19]
  1121.  
  1122.  
  1123. Internet Draft           TN3270 Enhancements               August 1993
  1124.  
  1125.  
  1126.       Another aspect of the BIND-IMAGE function alters the allowable
  1127.       DATA-TYPE flag values slightly from the behavior described in
  1128.       the section entitled "Basic TN3270E."  When BIND-IMAGE is in
  1129.       effect, data messages with DATA-TYPE set to 3270-DATA are not
  1130.       allowed before the first BIND-IMAGE is received by the client;
  1131.       only SCS-DATA or NVT-DATA can be used to transmit user-oriented
  1132.       data.  The same applies to data messages exchanged after an
  1133.       UNBIND is sent and before another BIND-IMAGE is received by the
  1134.       client.  Once the client receives a BIND-IMAGE data message,
  1135.       there are two possibilities:
  1136.  
  1137.       - for a terminal session, or for a printer session in which
  1138.         DATA-STREAM-CTL was negotiated, data messages following the
  1139.         BIND-IMAGE should have a DATA-TYPE of 3270-DATA.  (For
  1140.         terminals, this can change to SCS-DATA when the SYSREQ key is
  1141.         pressed.)
  1142.  
  1143.       - for a printer session in which SCS-CTL-CODES was negotiated,
  1144.         data messages following the BIND-IMAGE should continue to have
  1145.         a DATA-TYPE of SCS-DATA.
  1146.  
  1147.  
  1148.    10.4 The RESPONSE Function
  1149.  
  1150.       This function can be supported for both terminal and printer
  1151.       sessions connected to both SNA and non-SNA servers.
  1152.  
  1153.       Agreement to support this function requires that the party
  1154.       support the following TN3270E header values:
  1155.  
  1156.           Header field         Value
  1157.           ------------         -----
  1158.            DATA-TYPE          RESPONSE
  1159.            DATA-TYPE          REQUEST
  1160.            RESPONSE-FLAG      -all values-
  1161.            REQUEST-FLAG       ERR-COND-CLEARED
  1162.  
  1163.       When the RESPONSE function is in effect, each party must adhere
  1164.       to the following rules:
  1165.  
  1166.        - Whenever a data message is sent with a DATA-TYPE of either
  1167.          SCS-DATA or 3270-DATA, the sender must set the RESPONSE-FLAG
  1168.          field to either NO-RESPONSE, ERROR-RESPONSE, or
  1169.          ALWAYS-RESPONSE.  It is anticipated that the client side will
  1170.          normally set RESPONSE-FLAG to NO-RESPONSE.  The server, if it
  1171.          represents an SNA device, should set RESPONSE-FLAG to reflect
  1172.          the response value set in the RH of the RU that generated
  1173.          this data message - Definite Response resulting in a
  1174.          RESPONSE-FLAG value of ALWAYS-RESPONSE, Exception Response
  1175.          resulting in ERROR-RESPONSE being set, and No Response
  1176.          causing a setting of NO-RESPONSE.  A non-SNA server should
  1177.          set RESPONSE-FLAG to ERROR-RESPONSE.
  1178.  
  1179. B. Kelly                 Expires February 1994               [Page 20]
  1180.  
  1181.  
  1182. Internet Draft           TN3270 Enhancements               August 1993
  1183.  
  1184.  
  1185.        - Whenever a data message with a DATA-TYPE of either SCS-DATA
  1186.          or 3270-DATA is received, the receiver must attempt to
  1187.          process the data in the data portion of the message, then
  1188.          determine whether or not it should send a data message with a
  1189.          DATA-TYPE of RESPONSE.  If the data message it has just
  1190.          processed had a RESPONSE-FLAG value of NO-RESPONSE, or if it
  1191.          had a value of ERROR-RESPONSE and there were no errors
  1192.          encountered while processing the data, then no RESPONSE type
  1193.          message should be sent.  Otherwise, a data message should be
  1194.          sent in which the header DATA-TYPE field is set to RESPONSE.
  1195.          The RESPONSE-FLAG field in this header must have a value of
  1196.          either POSITIVE-RESPONSE or NEGATIVE-RESPONSE.  A
  1197.          POSITIVE-RESPONSE should be sent if the previously processed
  1198.          message's header specified ALWAYS-RESPONSE and no errors
  1199.          were encountered in processing the data.  A NEGATIVE-RESPONSE
  1200.          should be sent when
  1201.  
  1202.           1) the previously processed message specified ERROR-RESPONSE
  1203.              or ALWAYS-RESPONSE and
  1204.  
  1205.           2) some kind of error occurred while processing the data.
  1206.  
  1207.          Please keep in mind that it is normally only the client that
  1208.          will be constructing and sending these RESPONSE messages.  A
  1209.          negative response sent by the client to the server is the
  1210.          equivalent of a Unit Check Status [7].  All references to
  1211.          device status and sense codes in this section rely on [7].
  1212.  
  1213.          The data portion of this RESPONSE message must consist of one
  1214.          byte of binary data.  The value of this byte gives a more
  1215.          detailed account of the results of having processed the
  1216.          previously received data message.  The possible values for
  1217.          this byte are:
  1218.  
  1219.            For a RESPONSE-FLAG value of POSITIVE-RESPONSE -
  1220.  
  1221.              Value            Meaning
  1222.              -----            -------
  1223.              0x00      Successful completion (when sent by the client,
  1224.                        this is equivalent to "Device End").
  1225.  
  1226.            For a RESPONSE-FLAG value of NEGATIVE-RESPONSE -
  1227.  
  1228.              Value            Meaning
  1229.              -----            -------
  1230.              0x00      An invalid 3270 command was received
  1231.                        (equivalent to "Command Reject").
  1232.  
  1233.              0x01      Printer is not ready (equivalent to
  1234.                        "Intervention Required").
  1235.  
  1236.  
  1237.  
  1238. B. Kelly                 Expires February 1994               [Page 21]
  1239.  
  1240.  
  1241. Internet Draft           TN3270 Enhancements               August 1993
  1242.  
  1243.  
  1244.              0x02      An illegal 3270 buffer address or order
  1245.                        sequence was received (equivalent to
  1246.                        "Operation Check").
  1247.  
  1248.              0x03      Printer is powered off or not connected
  1249.                        (equivalent to "Component Disconnected").
  1250.  
  1251.          When the server receives any of the above responses, it
  1252.          should pass along the appropriate information to the host
  1253.          application.  The appropriate information is determined by
  1254.          whether the server represents an SNA or a non-SNA device.
  1255.  
  1256.          An SNA server should pass along a POSITIVE-RESPONSE from the
  1257.          client as a positive SNA Response Unit to the host
  1258.          application.  It should translate a NEGATIVE-RESPONSE from
  1259.          the client into an SNA negative Response Unit in which the
  1260.          Sense Data Indicator bit is on and which contains one of
  1261.          the following sense codes:
  1262.  
  1263.              RESPONSE-FLAG        Equivalent        SNA Sense Code
  1264.              -------------        ----------        --------------
  1265.                  0x00           Command Reject        0x10030000
  1266.  
  1267.                  0x01        Intervention Required    0x08020000
  1268.  
  1269.                  0x02           Operation Check       0x10050000
  1270.  
  1271.                  0x03        Component Disconnected   0x08310000
  1272.  
  1273.          A non-SNA server should pass along a POSITIVE-RESPONSE from
  1274.          the client by setting the Device End Status bit on.  It
  1275.          should reflect a NEGATIVE-RESPONSE from the client by setting
  1276.          the Unit Check Status Bit on, and setting either the Command
  1277.          Reject, Intervention Required, or Operation Check Sense bit
  1278.          on when responding to the Sense command.
  1279.  
  1280.          In the case of Intervention Required or Component
  1281.          Disconnected being passed by the server to the host
  1282.          application, the host would normally refrain from sending any
  1283.          further data to the printer.  If and when the error condition
  1284.          at the client has been resolved, the client must send to the
  1285.          server a data message whose header DATA-TYPE field is set to
  1286.          REQUEST, and whose REQUEST-FLAG is set to ERR-COND-CLEARED.
  1287.          Note that this message has no data portion.  Upon receipt of
  1288.          this message, the server should pass along the appropriate
  1289.          information to the host application so that it may resume
  1290.          sending printer output.  Again, the form of this information
  1291.          depends on whether the server represents an SNA or a non-SNA
  1292.          device.
  1293.  
  1294.  
  1295.  
  1296.  
  1297. B. Kelly                 Expires February 1994               [Page 22]
  1298.  
  1299.  
  1300. Internet Draft           TN3270 Enhancements               August 1993
  1301.  
  1302.  
  1303.          An SNA server should reflect an ERR-COND-CLEARED to the host
  1304.          application by sending an SNA LUSTAT RU with one of the
  1305.          following sense codes:
  1306.  
  1307.           - if the previous error condition was an Intervention
  1308.             Required, the server should send sense code 0x00010000
  1309.  
  1310.           - if the previous error condition was Component
  1311.             Disconnected, the server should send sense code 0x082B0000
  1312.  
  1313.          A non-SNA server should set the corresponding bits in the
  1314.          Ending Status and Sense Condition bytes.
  1315.  
  1316.  
  1317. 11. The 3270 ATTN Key
  1318.  
  1319.    The 3270 ATTN key is interpreted by many host applications in an
  1320.    SNA environment as an indication that the user wishes to interrupt
  1321.    the execution of the current process.  The Telnet Interrupt Process
  1322.    (IP) command was defined expressly for such a purpose, so it seems
  1323.    logical to use IP to implement support for the 3270 ATTN key.  This
  1324.    requires two things:
  1325.  
  1326.     - TN3270E clients should provide as part of their keyboard
  1327.       mapping a single key or a combination of keys that map to
  1328.       the 3270 ATTN key.  When the user presses this key(s), the
  1329.       client should transmit a Telnet IP command to the server.
  1330.  
  1331.     - TN3270E servers should translate the IP command received from
  1332.       a TN3270E client into the appropriate form and pass it along
  1333.       to the host application as an ATTN key.  In other words, the
  1334.       server representing an SLU in an SNA session should send
  1335.       a SIGNAL RU to the host application.
  1336.  
  1337.    The ATTN key is not supported in a non-SNA environment; therefore,
  1338.    a TN3270E server representing non-SNA 3270 devices should ignore
  1339.    any Telnet IP commands it receives from a client.
  1340.  
  1341.  
  1342. 12. The 3270 SYSREQ Key
  1343.  
  1344.    The 3270 SYSREQ key can be useful in an SNA environment when the
  1345.    ATTN key is not sufficient to terminate a process.
  1346.  
  1347.  
  1348.    12.1 Background
  1349.  
  1350.       In SNA, there is a session between the host application (the
  1351.       PLU, or Primary Logical Unit) and the TN3270E server
  1352.       representing the client (the SLU, or Secondary Logical Unit).
  1353.       This is referred to as the PLU-SLU session, and it is the one on
  1354.  
  1355.  
  1356. B. Kelly                 Expires February 1994               [Page 23]
  1357.  
  1358.  
  1359. Internet Draft           TN3270 Enhancements               August 1993
  1360.  
  1361.  
  1362.       which normal communications flow.  There is also a session
  1363.       between the host telecommunications access method (the SSCP, or
  1364.       System Services Control Point) and the SLU, and it is referred
  1365.       to as the SSCP-LU session.  This session is used to carry
  1366.       various control information and is normally transparent to the
  1367.       user.  For more information, refer to [7].
  1368.  
  1369.       The terminal display and keyboard are usually "owned" by the
  1370.       PLU-SLU session, meaning any data the user types is sent to the
  1371.       host application.  The SYSREQ key is used to toggle ownership of
  1372.       the keyboard and display between the PLU-SLU session and the
  1373.       SSCP-LU session.  In other words, the user is able to press
  1374.       SYSREQ and then communicate directly with the host SSCP.  The
  1375.       user may then enter any valid Unformatted Systems Services
  1376.       commands, which are defined in the USS table associated with the
  1377.       SLU.  The most common USS command users employ is "LOGOFF,"
  1378.       which requests that the SSCP immediately terminate the PLU-SLU
  1379.       session.  The usual reason for requesting such an action is when
  1380.       the host application (the PLU) has stopped responding
  1381.       altogether.
  1382.  
  1383.       Whenever the keyboard and display are owned by the SSCP-LU
  1384.       session, no data is allowed to flow in either direction on the
  1385.       PLU-SLU session.  Once "in" the SSCP-LU session, the user may
  1386.       decide to switch back to the PLU-SLU session by again pressing
  1387.       the SYSREQ key.
  1388.  
  1389.    12.2 TN3270E Implementation of SYSREQ
  1390.  
  1391.       The design of some TN3270E servers allows them to fully support
  1392.       the SYSREQ key because they are allowed to send USS commands on
  1393.       the SSCP-LU session.  Other TN3270E servers operate in an
  1394.       environment which does not allow them to send USS commands to
  1395.       the SSCP; this makes full support of the SYSREQ key impossible.
  1396.       For such servers, TN3270E provides for emulation of a minimal
  1397.       subset of functions, namely, for the sequence of pressing SYSREQ
  1398.       and typing LOGOFF that many users employ to immediately
  1399.       terminate the PLU-SLU session.
  1400.  
  1401.       The Telnet Abort Output (AO) command seems the appropriate
  1402.       mechanism for implementing SYSREQ key support, given that in a
  1403.       real SNA session, once the user presses the SYSREQ key, the host
  1404.       application is prevented from sending any more output to the
  1405.       terminal (unless the user presses SYSREQ a second time), but the
  1406.       user's process continues to execute.
  1407.  
  1408.       In order to implement SYSREQ key support, TN3270E clients should
  1409.       provide a key (or combination of keys) that is identified as
  1410.       mapping to the 3270 SYSREQ key.  When the user presses this
  1411.       key(s), the client should transmit a Telnet AO command to the
  1412.       server.
  1413.  
  1414.  
  1415. B. Kelly                 Expires February 1994               [Page 24]
  1416.  
  1417.  
  1418. Internet Draft           TN3270 Enhancements               August 1993
  1419.  
  1420.  
  1421.       Upon receipt of the AO command, the TN3270E server should enter
  1422.       what will be loosely termed "suspended mode" for the connection.
  1423.       Any attempt by the host application to send data to the client
  1424.       while the connection is "suspended" should be responded to by
  1425.       the server with a negative response, sense code 0x082D,
  1426.       indicating an "LU Busy" condition.  The server should not
  1427.       transmit anything to the client on behalf of the host
  1428.       application.  While the connection is "suspended," any data
  1429.       messages (except TN3270E responses) exchanged between the client
  1430.       and server should have the DATA-TYPE flag set to SCS-DATA.
  1431.  
  1432.       At this point, the behavior of the server depends upon whether
  1433.       or not it is allowed to send USS commands on the SSCP-LU
  1434.       session.  Servers that have this ability should simply act as a
  1435.       vehicle for passing USS commands and responses between the
  1436.       client and the SSCP.
  1437.  
  1438.       Servers that are not allowed to send USS commands on the SSCP-LU
  1439.       session should behave as follows:
  1440.  
  1441.       - if the user transmits the string LOGOFF (upper or lower case),
  1442.         the server should send an Unbind SNA RU to the host
  1443.         application.  This will result in termination of the PLU-SLU
  1444.         session.  The server should also send a data message to the
  1445.         client with the DATA-TYPE flag set to UNBIND.
  1446.  
  1447.       - if the user transmits anything other than LOGOFF, the server
  1448.         should respond with the string "COMMAND UNRECOGNIZED" to the
  1449.         client.  The server should not send anything to the host
  1450.         application on behalf of the client.
  1451.  
  1452.       Regardless of which kind of server is present (i.e., whether or
  1453.       not it may send USS commands on the SSCP-LU session), while the
  1454.       connection is suspended, the user may press the "SYSREQ" key
  1455.       again.  This will result in the transmission of another AO to
  1456.       the server.  The server should then send to the host application
  1457.       an LUSTAT RU with a value of 0x082B indicating "presentation
  1458.       space integrity lost."  The server will then "un-suspend" the
  1459.       Telnet connection to the client, meaning it will allow the host
  1460.       application to once again send data to the client.
  1461.  
  1462.       The SYSREQ key is not supported in a non-SNA environment; in
  1463.       fact, use of this key on a non-SNA 3270 terminal generally gets
  1464.       the user into difficulties.  Therefore, TN3270E servers
  1465.       representing non-SNA 3270 terminals should ignore any Telnet AO
  1466.       commands they receive from a client.
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474. B. Kelly                 Expires February 1994               [Page 25]
  1475.  
  1476.  
  1477. Internet Draft           TN3270 Enhancements               August 1993
  1478.  
  1479.  
  1480. 13. 3270 Structured Fields
  1481.  
  1482.    3270 structured fields provide a much wider range of features than
  1483.    "old-style" 3270 data, such as support for graphics, partitions and
  1484.    IPDS printer data streams. It would be unreasonable to expect all
  1485.    TN3270E clients to support all possible structured field functions,
  1486.    yet there must be a mechanism by which those clients that are
  1487.    capable of supporting some or all structured field functions can
  1488.    indicate their wishes.
  1489.  
  1490.    The design of 3270 structured fields provides a convenient means to
  1491.    convey the level of support (including no support) for the various
  1492.    structured field functions.  This mechanism is the Read Partition
  1493.    Query command, which is sent from the host application to the
  1494.    device.  The device responds with a Query Reply(s), listing which,
  1495.    if any, structured field functions it supports.
  1496.  
  1497.    Therefore, all TN3270E clients must be able to respond to a Read
  1498.    Partition Query command, even if only to indicate that it supports
  1499.    no structured field functions.  Note that clients must support both
  1500.    the Read Partition Query (Type 02), and all forms of the Read
  1501.    Partition Query List (Type 03).
  1502.  
  1503.  
  1504. 14. Examples
  1505.  
  1506.    The following example shows a TN3270E-capable server and a
  1507.    traditional tn3270 client establishing a connection:
  1508.  
  1509.       Server:  IAC DO TN3270E
  1510.       Client:  IAC WON'T TN3270E
  1511.       Server:  IAC DO TERMINAL-TYPE
  1512.       Client:  IAC WILL TERMINAL-TYPE
  1513.       Server:  IAC SB TERMINAL-TYPE SEND IAC SE
  1514.       Client:  IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
  1515.       Server:  IAC DO EOR IAC WILL EOR
  1516.       Client:  IAC WILL EOR IAC DO EOR
  1517.       Server:  IAC DO BINARY IAC WILL BINARY
  1518.       Client:  IAC WILL BINARY IAC DO BINARY
  1519.          (3270 data stream is exchanged)
  1520.  
  1521.    The following example shows a TN3270E-capable server and a
  1522.    TN3270E-capable client establishing a generic terminal session:
  1523.  
  1524.       Server:  IAC DO TN3270E
  1525.       Client:  IAC WILL TN3270E
  1526.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1527.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
  1528.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
  1529.                       anyterm IAC SE
  1530.  
  1531.  
  1532.  
  1533. B. Kelly                 Expires February 1994               [Page 26]
  1534.  
  1535.  
  1536. Internet Draft           TN3270 Enhancements               August 1993
  1537.  
  1538.  
  1539.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1540.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1541.          (3270 data stream is exchanged)
  1542.  
  1543.    The following example shows a TN3270E-capable server and a
  1544.    TN3270E-capable client establishing a terminal session where the
  1545.    client requests a specific device-name:
  1546.  
  1547.       Server:  IAC DO TN3270E
  1548.       Client:  IAC WILL TN3270E
  1549.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1550.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
  1551.                       CONNECT myterm IAC SE
  1552.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT
  1553.                       myterm IAC SE
  1554.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1555.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1556.          (3270 data stream is exchanged)
  1557.  
  1558.    The following example shows a TN3270E-capable server and a
  1559.    TN3270E-capable client attempting to establish a terminal session;
  1560.    multiple attempts are necessary because the device-name initially
  1561.    requested by the client is already in use:
  1562.  
  1563.       Server:  IAC DO TN3270E
  1564.       Client:  IAC WILL TN3270E
  1565.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1566.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
  1567.                       CONNECT myterm IAC SE
  1568.       Server:  IAC SB TN3270E DEVICE-TYPE REJECT REASON
  1569.                       DEVICE-IN-USE IAC SE
  1570.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2
  1571.                       CONNECT herterm IAC SE
  1572.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
  1573.                       herterm IAC SE
  1574.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1575.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1576.          (3270 data stream is exchanged)
  1577.  
  1578.    The following example shows a TN3270E-capable server and a
  1579.    TN3270E-capable client establishing a printer session where the
  1580.    client requests a specific device-name, and where some amount
  1581.    of 3270 function negotiation is required before an agreement is
  1582.    reached:
  1583.  
  1584.       Server:  IAC DO TN3270E
  1585.       Client:  IAC WILL TN3270E
  1586.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1587.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT
  1588.                       myprt IAC SE
  1589.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
  1590.                       myprt IAC SE
  1591.  
  1592. B. Kelly                 Expires February 1994               [Page 27]
  1593.  
  1594.  
  1595. Internet Draft           TN3270 Enhancements               August 1993
  1596.  
  1597.  
  1598.       Client:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
  1599.       Server:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL
  1600.                       RESPONSES IAC SE
  1601.       Client:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
  1602.       Server:  IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE
  1603.          (3270 data stream is exchanged)
  1604.  
  1605.    The following example shows a TN3270E-capable server and a
  1606.    TN3270E-capable client establishing first a generic terminal
  1607.    session, then a printer session where the "partner" printer for
  1608.    the assigned terminal is requested:
  1609.  
  1610.       Server:  IAC DO TN3270E
  1611.       Client:  IAC WILL TN3270E
  1612.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1613.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
  1614.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
  1615.                       termXYZ IAC SE
  1616.       Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
  1617.       Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
  1618.          (3270 data stream is exchanged)
  1619.            .            .
  1620.            .            .
  1621.          (user decides to request a printer session,
  1622.           so client again connects to Telnet port on server)
  1623.       Server:  IAC DO TN3270E
  1624.       Client:  IAC WILL TN3270E
  1625.       Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
  1626.       Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1
  1627.                       ASSOCIATE termXYZ IAC SE
  1628.       Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
  1629.                       termXYZ's-prt IAC SE
  1630.       Client:  IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES
  1631.                       RESPONSES IAC SE
  1632.       Server:  IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES
  1633.                       IAC SE
  1634.          (3270 data stream is exchanged)
  1635.  
  1636.  
  1637. 15. References
  1638.  
  1639. [1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM
  1640.     Corporation, January 1988.
  1641.  
  1642. [2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091,
  1643.     FTP Software, Inc., February 1989.
  1644.  
  1645. [3] Postel, J., and J. Reynolds, "Telnet Binary Transmission",
  1646.     RFC 856, USC/Information Sciences Institute, May 1983.
  1647.  
  1648. [4] Postel, J., "Telnet End of Record Option", RFC 885, USC/
  1649.     Information Sciences Institute, December 1983.
  1650.  
  1651. B. Kelly                 Expires February 1994               [Page 28]
  1652.  
  1653.  
  1654. Internet Draft           TN3270 Enhancements               August 1993
  1655.  
  1656.  
  1657. [5] "3270 Information Display System - Data Stream Programmer's
  1658.     Reference", publication number GA24-0059, IBM Corporation.
  1659.  
  1660. [6] "SNA Formats", publication number GA27-3136, IBM Corporation.
  1661.  
  1662. [7] "3174 Establishment Controller Functional Description",
  1663.     publication number GA23-0218, IBM Corporation.
  1664.  
  1665.  
  1666. 16. Author's Note
  1667.  
  1668.    Portions of this document were drawn from the following sources:
  1669.  
  1670.     - A White Paper written by Owen Reddecliffe, WRQ Corporation,
  1671.       October 1991.
  1672.  
  1673.     - Experimental work on the part of Cleve Graves and Michelle
  1674.       Angel, OpenConnect Systems, 1992 - 1993.
  1675.  
  1676.     - Discussions at the March 1993 IETF meeting.
  1677.  
  1678.     - Discussions on the "TN3270E" list, Spring/Summer 1993.
  1679.  
  1680.  
  1681. 17. Author's Address
  1682.  
  1683.    Bill Kelly
  1684.    Division of University Computing
  1685.    144 Parker Hall
  1686.    Auburn University, AL  36849
  1687.  
  1688.    Phone: (205) 844-4512
  1689.  
  1690.    Email: kellywh@mail.auburn.edu
  1691.  
  1692.  
  1693.  
  1694.  
  1695.  
  1696.  
  1697.  
  1698.  
  1699.  
  1700.  
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710. B. Kelly                 Expires February 1994               [Page 29]
  1711.  
  1712.  
  1713.  
  1714.